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ABSTRACT 


The  DREV98  image  format  was  developed  to  conduct  a  number  of  experiments 
on  the  transfer  of  metadata  between  an  auto-documented  sensor  and  an  auto-loading 
image  database.  These  experiments  allowed  us  to  determine  which  metadata  had  to  be 
stored  in  the  image  header.  Moreover,  this  image  format  brings  the  c  oncept  that  the 
header  segments  should  contain  meta-metadata,  i.e.  information  that  describes  the  header 
segment  data  (which  itself  describes  the  image)  allowing  a  universal  decoder  to  decode 
all  unkno  wn  s  egment.  This  technical  note  contains  the  description  of  the  DREV98 
image  format  and  the  new  concept  of  the  self-documented  header  segments. 

RESUME 

On  a  mis  au  point  le  format  d'image  DREV98  pour  effectuer  un  certain  nombre 
d'exp6riences  sur  le  transfert  de  meta-do nnees  entre  un  capteur  autodocumente  et  une 
base  de  donndes  a  chargement  automatique.  Ces  experiences  nous  ont  permis  de 
determiner  quelles  meta-donnees  devraient  dtre  sauvegardees  dans  l'en-tete  de  l'image. 
De  plus,  ce  format  d’image  amene  le  concept  que  les  segments  de  l’en-tete  pourraient 
contenir  des  meta-meta-donnees,  i.e.  de  l'information  qui  decrit  les  donnees  des  segments 
(lesquelles  decrivent  elles-memes  l’image),  permettant  a  un  decodeur  universel  de 
decoder  n'importe  quel  segment  inconnu.  Cette  note  technique  contient  la  description  du 
format  d'image  DREV98  et  du  nouveau  concept  de  segments  auto-documentes. 
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EXECUTIVE  SUMMARY 


Within  the  framework  of  the  ACIDE  (auto  Context  Image  Database  Exploitation) 
project,  an  ad-hoc  image  file  format  was  developed.  This  image  format  allowed  us  to 
control  the  parameters  of  an  experiment  which  consists  in  the  communication  of 
information  between  a  hypothetical  advance  sensor  able  to  auto-document  its  images  and 
a  database  capable  of  loading  automatically  the  image  metadata. 

This  image  format  was  not  developed  with  the  intention  of  being  in  competition 
with  COTS  image  formats.  It  was  rather  developed  to  see  which  information  should  be 
packaged  with  the  images  (which  the  current  formats  do  not  allowed).  This  was  useful  1) 
for  our  experiments  and  2)  t  o  m  ake  s  uggestions  t  o  up  grade  t  he  c  urrent  C  OTS  im  age 
formats. 
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1.0  INTRODUCTION 

This  technical  note  contains  information  about  the  "DREV98"  image  header. 
"DREV98-a"  is  the  keyword  that  begins  the  image  file  (the  8  first  bytes)  and  that  allows 
identifying  and  decoding  the  image  metadata  with  the  'DREV98'  subroutine  library 
version  '-a'. 

The  development  of  this  image  header  was  an  experiment  to  see  how  the  image  metadata 
could  be  encapsulated  in  a  dynamic  way  to  exchange  a  maximum  of  information  between 
an  auto-documented  sensor  and  a  receiving  image  database.  With  this  project,  it  was  not 
our  intent  to  be  in  competition  with  the  existing  COTS  image  formats  such  as  GIF,  PCI, 
TIFF  and  NITF  (Refs.  1,  2,  3),  but  rather  simply  to  be  able  to  package  the  information  we 
wanted  to  include  in  an  image  file,  which  is  not  currently  allowed  by  using  available 
COTS  image  formats. 

From  this  experiment,  a  number  of  interesting  concepts  have  emerged.  The  most 
important  concepts  that  are  worth  mentioning  are  listed  below: 

1  -The  header  identifies  the  numeric  representation  used  for  the  metadata  encoding:  then 

the  numbers  (integer,  float  or  anything  else)  can  be  read,  no  matter  the  original 
processor  used  to  encode  the  image  (Intel  processors  are  'big  endian'  (most  significant 
byte  right),  while  the  other  processors  are  usually  'little  endian'  (most  significant  byte 
left). 

2  -The  header  length  is  variable  and  as  many  secondary  segments  as  necessary  can  be 
stringed  together. 

3  -  The  needs  for  a  number  of  secondary  header  segments  have  been  identified, 
developed  and  tested. 

4-  The  secondary  header  segments  indicate  themselves  which  subroutines  must  be  used  to 
decode  them. 

5  -The  secondary  header  segments  are  self-documented  and  it  is  possible  to  decode  an 
unknown  segment  encoded  by  a  third  party,  even  if  this  segment  has  never  been  seen 
before.  This  last  point  is  the  most  interesting  one  because  it  raises  the  concept  of 
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meta-metadata,  i.e.  a  piece  of  code  that  can  be  read  inside  the  image  header  that  allows 
us  to  decode  the  following  part  of  the  header  (metadata) . 

The  information  presented  in  this  technical  note  concurs  exactly  with  the  image 
format  developed.  The  subroutine  libraries  were  developed  into  two  versions,  one  in 
FORTRAN  and  the  other  in  C.  Both  libraries  were  tested  on  a  SUN  workstation  and  the 
C  version  was  also  tested  on  a  PC  computer.  If  a  new  version  of  this  image  format  needs 
to  be  produced,  some  recommendations  are  presented  in  Chapter  5. 

This  technical  note  only  documents  what  has  been  done  about  the  experimental 
DREV98  image  format.  However,  if  it  is  required  that  a  deliverable  product  be 
developed,  the  recommendations  in  Chapter  5  will  have  to  be  included.  This  has  not 
been  done  yet  because  it  was  not  our  intent  to  develop  ready-to-use  software  (this  was  in 
fact  part  of  a  larger  experiment)  and  no  more  resources  have  been  allocated  to  this  sub- 
project.  Moreover,  it  was  concidered  better  to  use  a  recognized  image  format  like  NITF 
(ref.  3)  to  keep  on  with  our  experiments.  Nevertheless,  some  good  ideas  have  emerged 
and  justify  the  publication  of  this  note.  These  ideas  can  even  be  communicated  to  the 
persons  in  charge  of  the  recognized  image  formats  (like  NITF)  to  have  them  create  a  new 
version  that  could  incorporate  new  information  encoding  concepts  (particularly  Sections 
4.3  and  5.3). 

This  work  was  performed  at  DREV  between  December  1997  and  September  1998 
under  PSC  5EB12,  “Space-Based  IR  Surveillance”. 
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2.0  THE  HEADER  STRUCTURE 

The  structure  of  the  image  file  is  presented  in  Fig.  1.  This  image  file  is  composed 
of  a  fixed  size  main  header  (344  bytes),  a  series  of  concatenated  secondary  header 
segments  and  finally  the  image  data. 


t 


main  header 


secondary  header  1 


secondary  header  n 


IMAGE 


J  v 


344  bytes  SH1_NB  bytes 


SHn  NB  bytes  IMB  bytes 


SHB  bytes 


FIGURE  1  -  Structure  of  the  image  file 

The  total  length  of  the  secondary  header  segments  is  recorded  in  the  variable  SHB 
and  stored  in  the  main  header  (byte  341  to  344).  Similarly,  the  total  length  of  the  image 
is  recorded  in  the  variable  IMB  and  stored  in  the  main  header  (byte  337  to  340). 
Therefore,  it  is  easy  to  access  directly  the  image  by  skipping  the  secondary  header. 

The  secondary  header  is  composed  of  a  multitude  of  concatenated  segments  of 
various  formats.  It  is  very  easy  to  navigate  in  the  secondary  header  because  the  segment 
are  composed  by  following  strict  rules  described  in  Chapter  4.  For  once,  let  us  say  that 
each  segment  begins  with  an  integer  number  (four  bytes)  that  indicates  its  length. 
Therefore,  it  is  easy  to  skip  from  a  segment  to  another  one  just  by  skipping  this  number 
of  bytes. 
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3.0  THE  MAIN  HEADER 

The  main  header  is  a  fixed  length  structure.  It  contains  all  the  information 
(presented  in  Table  I)  necessary  to  decode  the  secondary  header  segments  and  the  image 
data.  The  definition  of  the  variables  follows  the  table. 

The  first  string  that  must  be  read  in  a  DREV98  image  file  is  the  first  eight  bytes  to 
recognize  the  header  format.  If  the  test  is  successful,  the  344  first  bytes  are  read  to  obtain 
the  complete  main  header  block.  Then  the  variable  LITTLE_OR_BIG_ENDIAN 
indicates  how  the  number  must  be  read.  In  fact,  this  variable  set  a  flag  in  the  header 
decoding  method  and  depending  on  the  encoded  file  and  the  kind  of  computer,  the 
conversion  of  the  numerical  values  are  done  appropriately  (byte  swapping). 

The  other  information  contained  in  the  main  header  (MHD)  is  the  original  file 
name  and  creation  date,  image  dimensions  and  numerical  representation  and  total  number 
of  bytes  of  the  secondary  headers  and  image.  Now,  if  the  user  wishes  to  read  the  image 
without  decoding  the  secondary  header  segments,  he  can  skip  directly  to  the  image  data. 

The  content  (and  structure)  of  the  MHD  is  presented  in  Table  I,  while  the 
description  of  the  variables  is  presented  in  Table  II.  The  data  types  supported  by  the 
DREV98  image  format  are  listed  in  Table  III. 


T 


1 
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TABLE  I 

Content  of  the  main  header 


Byte  Number  Type  Variable  name 

number _ of  bytes _ 

1-8  8  char[8]  HEADERJD 

9  -  264  256  char[256]  FILE  NAME 

265-  296  32  char[32]  CREATION_DATE 

297-  300  4  long  IMAGESAMPLE 

301-  304  4  long  IMAGELINE 

305-  308  4  long  IMAGE_BAND 

309-  312  4  long  IMAGE_FRAME 

313-316  4  long  IMAGECAMERA 

317-  320  4  long  IMAGE_SPECIAL 

321-  324  4  char[4]  PIXELENCODINGTYPE 

325-  328  4  char[4]  LITTLEOR JB  IG_ENDIAN 

329-  336  8  char[8]  COMPRESSION_TYPE 

337-  340  4  long  IMAGEJBYTES 

341-  344  4  lon8  SECOND ARY_HEADER_BYTES  (SHB) 
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TABLE  II 


Description  of  the  variable  of  the  main  header 


Variable 

Description 

HEADERJD 

Contain  the  magic  character  string  which  allows  to 
identify  this  header.  This  character  string  is,  for  the 
current  version;  'DREV98-a'. 

FILEJNfAME 

This  field  contains  the  name  of  the  file  when  it  was 
created.  Even  if  the  file  has  been  moved,  this  field  still 
contain  the  original  name. 

CREATION  DATE 

Creation  date  of  this  file 

IMAGE  SAMPLE 

Number  of  samples  per  image  line 

IMAGE  LINE 

Number  of  lines  per  image  frame 

IMAGE  BAND 

Number  of  image  bands 

IMAGE  FRAME 

Number  of  frames  in  the  image  sequence 

IMAGECAMERA 

Number  of  views  or  cameras  in  this  archive,  e.g., 
stereoscopic  image  pairs  require  to  have  a  left  and  a 
right  camera,  thus  2  cameras. 

IMAGE_SPECIAL 

Special  dimensions  for  a  special  application,  for 
example  for  images  acquired  with  different  polarization 
angles.  Hence,  with  these  six  dimensions,  it  is  possible 
to  record  a  sequence  of  stereoscopic  color  images 
acquired  in  polarized  light. 

PIXEL  ENCODING  TYPE 

Numeric  data  type  of  the  image  (see  Table  III). 

LITTLE_OR_BIG_ENDIAN 

This  variable  is  'L...'  for  little  endian  or  rB...'  for  big 
endian.  Little  endian  (or  less  significant  byte  right)  is 
used  by  CPUs  like  Motorola  (series  68000  ),  SUN 
(Spark),  while  big  endian  (or  most  significant  byte 
right)  is  used  by  IBM  PCs  CPUs  like  the  x86  series  and 
Pentium  (Intel  processors). 

COMPRES  SION_T  YPE 

Identification  of  the  algorithm  used  to  compress  the 
image. 

IMAGE  BYTES 
(IMB) 

Number  of  bytes  of  the  image.  If  no  compression  is 
used,  then  this  size  is: 

IMAGE  BYTES  =  (  [SAMPLE  *  LINE  * 

BAND  *  FRAM  *  CAMERA  *  SPECIAL  * 
nbbitsof  (PIXEL_ENCODlNG_TYPE)]  +7  )  /  8 
If  a  compression  is  used,  then  the  appropriate  method 
must  be  called  (no  compression  method  is  implemented 
in  version  DREV98-a). 

SECONDARY  HEADER 

BYTES 

(SHB) 

Total  number  of  bytes  used  by  the  secondary  header 
segments 
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The  function  named  "nbbitsof'  (used  in  the  calculation  of  the  image  size)  is  a 
function  that  returns  the  number  of  bits  associated  to  the  code  contained  in  the  variable 
PIXEL_ENCODING_TYPE,  e.g.  "nbbitsof(  'ui8' )"  returns  the  number  64. 

TABLE  III 

Data  type  supported  by  the  DREV98  image  format 


Type 


1 

2 

4 

12 

b 

c _ 

ub 

i2 

ui2 

i4 

ui4 

i8 

ui8 

f 

d 

Id 

_c _ 

dc 

rgb 


rgbt 


Number  of 
bits  per 
pixel 


Description 


12 


16 


16 


32 


32 


64 


64 


32 


64 


128 


64 


128 


24 


logical*  1  1  bit  graphic _ 

logical*2  2  bit  graphic _ 

logical*4  4  bit  graphic _ 

unsigned  12  bit  integer  (0  to  1023) 

byte  (-128  to  127) _ 

character _ 

unsigned  byte  or  char  (0  to  255) _ 

short  integer _ 

unsigned  short  integer _ 

long  integer _ 

unsigned  long  integer _ 

long  long  integer _ 

unsigned  long  long  integer _ 

float _ 

double _ 

long  double _ 

complex _ 

double  complex _ 

24  bits  RGB:  8  bits  RED,  8  bits  GREEN,  8  bits 

BLUE _ 

32  bits  RGB  with  transparency: 

8  bits  RED,  8  bits  GREEN,  8  bits  BLUE, 

8  bits  transparency. _ 


32 
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4.0  THE  SECONDARY  HEADER  SEGMENTS 

While  the  main  header  is  a  fix-block-size  data  that  allows  begin  decoding  of  the 
file,  t  he  s  econdary  he  ader  is  a  v  ariable  1  ength  s  tructure  composed  of  many  segments 
concatenated  together.  Here  is  the  description  of  the  composition  of  the  segments. 

4.1  Why  Adding  Secondary  Header  Segments 

There  are  very  complex  and  very  complete  COTS  image  formats.  For  example, 
TIFF  is  very  good  standard  extensively  used.  However,  what  happens  when  one  needs  to 
include  a  new  kind  of  information  in  an  image  file?  He  needs  to  create  a  new  image 
format.  Hence,  TIFF  cannot  record  the  geographic  reference  but  GEO-TIFF  can. 

The  PCI  image  file  format  has  the  capability  of  adding  secondary  header 
segments  to  its  files,  which  is  already  better  than  the  TIFF  format.  However,  the  nature 
of  these  segments  is  pre-defined  and  it  is  not  possible  to  create  new  specialized  segments, 
except  if  you  agree  that  no  one  else  c  an  decode  them  or  simply  encode  you  specific 
information  with  ASCII  characters,  which  is  a  big  constraint.  Nevertheless,  with  PCI,  it 
is  not  necessary  to  develop  a  new  image  format  every  time  a  new  information  must  be 
saved. 

4.2  The  Generalization  of  the  Header  Segments 

What  is  needed  is  a  convention  that  allows  to  create  an  image  format  convenient 
enough  to  include  custom  information  and  wise  e  nough  to  decode  it  w  ithout  a  p  riori 
knowledge  provided  by  the  creator.  This  is  not  really  feasible,  except  that  the  required  a 
priori  knowledge  can  be  encapsulated  by  the  creator  inside  the  segment  itself.  Thus,  a 
convention  for  the  encoding  and  decoding  of  this  a  priori  knowledge  is  required  and  this 
idea  is  supported  by  the  DREV98  format.  Hence,  it  will  be  possible  to  create  new 
segment  types  without  having  to  update  the  decoding  library.  Unfortunately,  this  concept 
has  not  been  exploited  to  its  limits  and  some  recommendations  are  made  in  the  next 
Chapter. 


r 
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4.3  Description  of  the  Structure  of  the  DREV98  Secondary  Header  Segments 

The  secondary  header  segment  (SH),  presented  in  Fig.  2,  can  be  used  to  store  any 
kind  of  information  relevant  to  the  image.  It  is  composed  of  a  fixed  length  segment 
header,  a  variable-size  segment  descriptor  and  a  variable-size  storage  area.  The 
description  of  the  segment  header  variables  is  presented  in  Table  IV. 


bytes: 

1 

4-5 

36-37 

40-41 

41+SHi  DL 

jvjf  p  » ij  J  vp 

mUtS 

SHiJDL 

SHi-DATA 

optional 


FIGURE  2  -  Structure  of  the  variable-length  secondary  header  segment 

Since  the  secondary  header  is  composed  of  many  segment,  the  variables,  in  the 
following  description,  are  indexed  par  the  letter  T.  Hence,  the  variable  SHi  NB 
represents  the  number  of  bytes  (SH_NB)  of  the  ith  segment. 

The  first  information  encountered  in  this  segment  is  its  length  (SHi_NB).  Hence, 
if  one  does  not  want  to  decode  this  segment,  he  just  has  to  skip  this  number  of  bytes  to 
reach  the  next  segment.  This  task  is  performed  by  a  function  called  'SHD_GET_NEXT' 
from  the  experimental  library  that  was  developed  during  this  experiment.  This 
particularity  allows  to  string  the  segments  and  access  them  as  if  the  secondary  header 
were  a  sequential  magnetic  tape. 

The  second  information  is  the  identification  of  the  segment  (SHiHD).  Thus,  by 
knowing  the  segment  name,  it  is  now  possible  to  call  the  subroutine  (or  method)  that  will 
be  able  to  decode  it.  Here,  it  is  strongly  recommended  to  identify  the  segment  with  the 
same  name  as  that  of  the  subroutine  used  to  decode  it.  An  example  is  presented  in  Table 
IV.  Also,  in  the  experimental  library,  a  useful  function  was  developed  to  have  the  next 
occurrence  of  a  segment  identified  by  its  name.  Hence,  for  example,  one  can  get  directly 
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the  'GEOREFERENCES'  segment  without  having  to  decode  the  entire  SHD  but  only  by 
calling  a  function  like  "SHDSEAK  (’GEOREFERENCES')". 

The  next  information  stored  in  the  segment  header  is  the  segment-format 
descriptor.  This  descriptor  has  two  fields;  an  integer  (SHiJDL),  which  indicates  the 
length  of  the  character  string,  and  the  character  string  (SHi_DS)  which  contains  the 
format  of  the  data  saved  in  this  segment.  In  the  current  version  of  the  DREV98  file 
format,  the  content  of  this  string  is  more  a  comment  (ASCII  syntax)  that  can  be  read  by 
the  programmer  (who  can  write  a  new  segment  decoder  when  this  segment  is  unknown) 
than  a  coded  instruction  auto-interpreted  by  a  generalized  segment  decoder.  More  details 
are  discussed  in  the  next  Chapter. 

Finally,  the  last  information  stored  in  the  segment  is  an  array  (SHi  DATA)  which 
contains  the  image  metadata  for  which  this  segment  is  design.  The  length  of  this  buffer  is 
the  total  length  of  the  segment,  less  the  length  (SHi_DL)  of  the  description  string 
SHi_DS,  less  the  length  of  the  fixed  part  the  segment  header  (40  bytes),  i.e. 

Data  length  (in  bytes)  =  SHi  NB  -  SHi  DL  -  40. 

This  array  can  contain  almost  everything.  For  example,  with  the  following  example: 

SH_NB  =  89  +  12  *  N  bytes. 

SHJDD  =  'SENSOR  C AMERA  SETUP  ' 

SHDL  =  41 

SH_DS  =  'long  N,  1  (float),  N(long[  1  ]),  N(float[2])' 

SH_DATA  =  ...  the  (12  *  N)  +  8  following  bytes. 

the  data  buffer  contains  one  integer  called  'N'  (4  bytes),  one  float  (4  bytes),  an  integer 
vector  (whose  length  is  determined  by  the  content  of  the  integer  rN’)  and  a  (two  columns 
by  TSP  row)  float  matrix. 
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TABLE  IV 

Description  of  the  variable  of  the  header  part  of  the 
secondary  header  segment 


SHiJSIB 

long 

Secondary  Header  _  Number  of  Bytes: 

Total  length  (in  bytes)  of  this  segment. 

SHiJD 

character*32 

Secondary  Header  _  Identification: 

String  which  identifies  this  data  segment.  It  is  strongly 
recommended  that  this  name  matches  the  name  of  the  routine 
used  to  decode  this  segment,  e.g.: 

SH_ID  =  ’GEOREFERENCES' 

Related  routines: 

GEO  REFERENCES  CREATE 

GEO  REFERENCES  TRANSLATE 

GEO  REFERENCES  GET 

GEO_REFEREN  CES_PRINT 

SHiDL 

long 

Secondary  Header  _  Description  Length: 

SHi  DL  =  0  if  the  field  SHi  DS  is  not  used. 

Length  of  the  character  string  which  describes  the  data  in 

The  SHi_DATA  field. 

SHi_DS 

char*SHi_DL 

Secondary  Header  _  Description  String  (meta-metadata) 

String  that  may  contain  the  formats  description  and  maybe 
the  data  titles.  This  is  particularly  useful  for  new  secondary 
header  segments  developed  by  new  users  and  which  are 
unknown  by  the  original  DREV98-a  software  package. 

Hence,  the  information  required  to  decode  foreign  header 
segments  may  be  provided  inside  this  foreign  segment 
itselfs. 

e.g.:  (for  the  segment  GEOREFERENCES) 

SH  DL  =  32 

SH_DS  —long  N,  N(long[9]),  N(double[8])’ 

This  segment  begins  with  a  long  integer  ’N',  followed  by  N 
vector  of  9  long  elements  and  followed  by  N  vector  of  8 
double  elements. 

mu 

mH 

Specific  to  each  header  segments 

The  length  of  data  is  (SHi  NB  -  SHi  DL  -  40)  bytes  | 
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5.0  RECOMMENDATIONS  FOR  THE  NEXT  VERSION 

The  e  xperimentation  w  ith  t  he  c  urrent  v  ersion  ha  s  s  hown  s  ome  1  imitations  a  nd 
bugs.  Here  are  the  modifications  that  will  be  included  in  the  next  version  of  this  image 
format. 

5.1  Bug  in  Fortran  Encoding  to  C  Decoding 

The  libraries  of  functions  (for  the  header  coding,  decoding  and  manipulation) 
have  been  encoded  in  parallel  in  C  and  in  Fortran  languages.  Both  libraries  work  very 
well  independently  of  the  computer  platform  (tested  on  PC  and  SUN  workstations). 
However,  a  bug  was  found  between  the  headers  encoded  with  the  Fortran  library  and 
decoded  by  the  C  library.  The  C  functions  expect  that  the  character  strings  be  terminated 
by  a  null  character  ("\0'),  what  the  Fortran  version  is  not.  Thus,  it  must  be  specified  as  a 
standard  that  every  character  strings  be  explicitly  ended  by  a  '\0',  whatever  the  compiler 
used  to  develop  the  library,  i.e.  *\0*  becomes  an  element  of  the  header  definition  and  not 
just  a  particularity  of  certain  compilers. 

5.2  Identification  of  the  Segments 

In  the  current  version,  a  32-character  string  is  allocated  to  the  variable  SHiJCD.  In 
some  cases  this  may  not  be  enough.  A  64  (or  even  a  128)  bytes  buffer  would  be  better. 
A  variable- length  string  could  be  even  better  and  done  by  adding  another  parameter  to  the 
segment  header,  like  "SHi_IDL"  ( Secondary  H eader  Identification  Length)  b efore  t he 
parameter  "SHi_ID". 

5.3  Segment  Format  Descriptor 

In  the  example  presented  in  the  previous  chapter,  i.e.: 

SHJDL  =  41 

SH JDS  =  'long  N,  1  (float),  N(long[  1  ]),  N(float[2])' 


r 
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SHJDS  contains  a  string  (of  41  characters)  readable  by  the  programmer.  If  this  segment 
were  unknown,  he  could  write  a  new  subroutine  to  decode  the  information  contained  in 
this  segment.  However,  this  syntax  (in  a  'C'  like  style)  is  not  formal  enough  to  be 
automatically  decoded  by  a  generalized  segment  decoder.  A  formal  syntax  should  be 
defined  and  a  parser  developed  to  decode  it.  This  syntax  should: 

-  contain  local  integer  variable  for  variable-length  array  description  (e.g.:  $N,  $M) 

-  support  numeric  representation  presented  in  Table  III  (e.g.:  i4,  f,  c,  etc.), 

-  support  vector  and  array  definition  using  parentheses  (e.g.  f(N,2)  ), 

-  support  repeating  structure  indicators  (e.g.  2f(n,2)  ). 

Hence,  the  previous  example  could  become: 

SH_DL  =  17 

SHJDS  =  ’$N,f,i4(N),f(N,2)' 

In  this  example,  $N  means  that  an  integer  (4  bytes)  must  be  read  and  assigned  to 
the  variable  N'  and  the  value  of  this  variable  is  reused  in  the  definition  of  the  arrays, 
which  are  an  integer*4  vector  of  N  elements  and  a  (N,2)  float  matrix. 

With  such  a  syntax,  the  programmer  does  not  need  anymore  to  write  ad-hoc 
functions  because  a  single  all-purpose  function  could  be  used  to  decode  every  unknown 
segment.  Furthermore,  the  unknown  segments  could  also  contains  strings  (also  self 
decoded,  e.g.,  ’c(28)’  for  a  vector  of  28  characters)  that  document  the  data  they  contain 
(like  a  table  title). 
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6.0  CONCLUSION 

The  image  file  format  presented  here  was  very  useful  to  perform  a  number 
experiments  on  the  communication  of  information  between  a  sensing  system  and 
database  with  a  capability  of  automatic  information  loading.  The  development  of 
software  related  to  this  image  file  format  has  not  been  fully  completed,  but  this  study 
contains  ideas  that  worth  being  written. 

The  file  format  developed  here  was  useful  to  communicate  information  on  the 
sensor  setup  to  the  database  (optics  setup,  navigation  parameters,  etc.),  which  could  not 
be  done  with  other  formats.  However,  rather  than  keeping  on  with  the  development  of  an 
ad-hoc  image  format,  it  has  been  decided  to  add  ad-hoc  header  segment  to  other  COTS 
image  formats  or,  even  better,  to  influence  the  development  of  these  COTS  formats. 

The  concept  of  self-documented  secondary-header  segment  for  the  automatic 
decoding  of  unknown  segments  is  something  that  has  never  been  seen  in  any  image 
format  description.  This  concept  of  meta-meta-data  (i.e.  the  data  that  describes  the  data 
that  documents  the  data)  needs  to  be  further  developed  and  proposed  to  a  recognize 
image  format  like  NITF  for  integration.  If  applied,  only  a  parser  is  required  to  decode  the 
image  metadata  and  no  more  new  version  of  image  format  will  be  necessary.  It  will  be 
possible  to  include  new  classes  of  data  inside  the  image  header  (without  defining  a  new 
version  of  file  format)  and  the  end  user  will  still  be  able  to  decode  this  new  class  of 
information  without  updating  the  image  decoding  software. 


T 
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APPENDIX  A 


This  appendix  contains  examples  (with  simulated  data)  of  the  use  of  the  header 
DREV98  and  the  seven  secondary  header  segments  that  have  a  Iready  been  encoded. 
These  segments  are  called; 

COMPONENT JDDENTIFICATION, 

SENSOR_ACQUISlTION_TIME, 

SEN  S  OR_C  AMERA_SETUP, 

SENSOR_BAND_DEFINITION, 

SENSORFLIGHT, 

SENSOR  CAMERA  POINTING  and 
GEOREFERENCES. 

Moreover,  they  can  be  used  more  than  once  in  the  secondary  header.  For  example,  the 
segment  COMPONENT  JDDENTIFICATION'  could  be  used  five  times  to  identify  1)  the 
camera,  2)  the  optics,  3)  a  filter,  4)  the  carrying  platform  and  5)  the  pointing  system. 

A.l  Example  of  Printing  of  Information  Contained  in  the  Main  Header 

The  following  example  shows  the  metadata  saved  in  the  image  main  header.  One 
can  see  the  file  name,  creation  date,  the  image  dimensions,  the  pixel  definition,  the  image 
size  and  the  size  of  the  secondary  header.  The  decoding  of  this  secondary  header  is 
shown  in  the  next  section. 


Content  of  the  main  image  header  (DREV98-a) : 


Original  file  name  : 

test_01 

Creation  date  : 

Mon  Feb  09  13:47:52  1998 

Image  format: 

SAMPLE 

= 

512 

LINE 

= 

512 

BAND 

s 

3 

FRAME 

= 

67 

CAMERA 

SK 

1 

SPECIAL 

1 

Pixel  format : 

PIXEL_ENCODING_TYPE 

= 

Mi4  "  i.e.:  integer* 4  or  long 

Endian  : 

B:  big  endian 

Compression  type  : 

none 

Number  of  image  bytes  :  210763776 


-  Number  of  bytes  in  the  secondary  header: 


2807 
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A.2  Secondary-Header  Segment:  COMPONENT  IDENTIFICATION 

This  segment  contains  the  identification  of  a  specific  component.  This 
component  can  be  for  example:  CAMERA,  POINTING_SYSTEM,  PLATFORM, 

OPTICS,  FILTER,  and  others  ... 

Segment  Description: 


Byte 

Type 

Description 

1-4 

long 

SH  NB  =  178 

5-36 

char*32 

SH  ID  = 'COMPONENT  IDENTIFICATION’ 

37-40 

long 

SH  DL  =  10 

41-50 

char*  10 

SH_DS  = ’4(char*32)' 

51-  82 

char*32 

COMPONENT  TYPE 

83-114 

char*32 

COMPONENT  NAME 

115-146 

char*32 

SERIAL  NUMBER 

147-178 

char*32 

COMPANY 

Example  of  Printing  Result:  (Simulated  Data) 


*  Segment  index  =  1,  segment  length  =  178  bytes. 

Component  identification: 

Component  :  Camera 

Model:  K8900 

Serial  number:  234E5SY 
Company  :  Kodak 


*:  -  The  segment  index  is  the  byte  number  (in  the  secondary  header  string)  where  this 
segment  begins  (1  in  this  example),  but  it  can  be  anything  else,  see  the  following 
examples.. 

-  The  segment  length  is  the  value  indicated  by  the  variable  SH_NB. 
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A.3  Secondary-Header  Segment:  SENSOR_ACQUISITTON_TIME 

This  segments  contains  the  information  about  date  and  time  of  acquisition 


Segment  Description: 


Byte 

Type 

Description 

1-  4 

long 

SH  NB  =  72 

5-36 

char*32 

SH  ID  =  'SENSOR  ACQUISITION  TIME’ 

37-40 

long 

SH  DL  =  8 

41-48 

char*  8 

SHDS  =  '6(float>' 

49-52 

float 

START  TIME  YEAR 

53-56 

float 

START  TIME  MONTH 

57-60 

float 

START  TIME  DAY 

61-64 

float 

START  TIME  HOUR 

65-68 

float 

START  TIME  MINUTE 

69-72 

float 

START  TIME  SECOND 

Example  of  Printing  Result:  (Simulated  Data) 


Segment  index  *  179,  segment  length  =  72  bytes. 


Sensor  acquisition  time: 


Year : 

Month : 

Day: 

Hour: 

Minute: 

Second: 


1998. 

1. 

12. 

11. 

29. 

30.0000 
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A.4  Secondary-Header  Segment:  SENSOR_CAMERA_SETUP 

This  segment  contains  the  initial  setup  of  the  camera  plus  a  list  of  parameters 
(indexed  by  the  frame  number),  which  can  change  in  time. 

Segment  Description: 


e m 

Description 

1-  4 

long 

SHNB  =  93  +  12  *  NB  OF  REFERENCED  FRAME  bytes. 

5-36 

char*32 

SH  ID  =  SENSOR  CAMERA  SETUP 

37-40 

long 

SHDL  =  41 

41-81 

char*41 

SHJDS  =  'long  N,  l(float),  N(long[l]),  N(float[2])' 

82-85 

long 

NB  OF  REFERENCED  FRAME 

86-89 

float 

CAMERA  FRAME  RATE 

90-93 

float 

PIXEL  INTEGRATION  TIME 

94-- 

long[][l] 

FRAME  INDEX 

fioatnm 

CAMERA  SETUP 

Table  Definitions: 


long  FRAME_INDEX  [1]  :  frame  number  where  the  following  data  is  applicable. 

float  CAMERASETUP  []  [2]  : 

[0] :  FOCAL  LENGTH 

[1] :  APERTURE  (diaphragm) 

Example  of  Printing  Result:  (Simulated  Data! 


;  index 

=  251,  segment 

3=sss:  =  s  =  =:=s: 

length  = 

Setup : 

Number 

of  referenced  frames: 

Frame 

rate: 

3 

Pixel 

integration  time 

: 

Setup : 

Frame 

Focal 

Aperture 

index 

length 

- 

(m) 

(m) 

1 

0 . 1350 

0.0700 

4 

0.1350 

0.0700 

6 

0.1350 

0.0600 

9 

0.1400 

0.0550 

12 

0.1403 

0.0510 

14 

0.1466 

0.0480 

19 

0.1487 

0.0475 

32 

0.1500 

0.0467 

189  bytes. 


0.0170  second . 
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A.5  Secondary-Header  Segment:  SENSOR_BAND_DEFINITION 

This  segment  contains  the  information  that  describes  the  wavelength  limits  of  the 
wavebands  specified  by  the  band  index. 


Segment  Description: 


Byte 

Type 

Description 

1-  4 

long 

SH  NB=  75  +  28  *  NB  OF  DESCRIBE  BAND  bytes. 

5-36 

char*32 

SH  ID  =  'SENSOR  BAND  DEFINITION' 

37-40 

long 

SH  DL=  31 

41-71 

1 

char*  31 

SH_DS  =  'long  N,  N(long[l]),  N(float[6])' 

72-75 

long 

NB  OF  DESCRIBE  BAND 

76-- 

long[]  [1] 

BAND  INDEX 

-  -  - 

float[]  [6] 

WAVEBAND  DESCRIPTION 

Table  Definitions: 


long  BAND_INDEX  []  [1]  :  Band  number  where  the  following  data  is  applicable 

float  WAVEBAND_DESCRIPTION  []  [2]  : 

[0] :  WAVELENGTH JsdINIMUM 

[1]  :  WAVELENGTH JsIAXIMUM 

[2]  :  FIRST  HYPERSPECTRAL  CHANNEL 

[3]  :  LAST  HYPERSPECTRAL  CHANNEL 

[4]  :  BAND  ACQUISITION  TIME  * 

[5]  :  PIXEL_INTEGRATION_TIME  * 

*:  different  for  image  scanner,  equal  for  mosaic  detector. 


Example  of  Printing  Result:  (Simulated  Data) 


Segment  index  *  440,  segment  length  =  111  bytes. 

Band  definition; 

Number  of  referenced  bands:  3 


Band 

Minimum 

Maximum 

First 

Last 

Acq. 

Pixel  acc 

index 

wavelength 

wavelength 

channel 

channel 

time 

time 

- 

(um) 

(um) 

<s) 

(s) 

1 

3.000 

4.200 

1 

3 

0.021 

0.00018 

2 

4.200 

4.400 

4 

4 

0.021 

0.00018 

3 

4.400 

5.100 

5 

7 

0.021 

0.00018 
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A.6  Secondary-Header  Segment:  SENSOR_FLIGHT 

This  segment  contains  the  information  that  describes  the  sensor  attitude  for  a 
number  of  frames  (specified  by  the  frame  index)  of  the  image  sequence. 

Segment  Description: 


Byte 

E553SH1 

Description 

1-  4 

long 

SH_NB=  77+  100  *  NB  OF  REFERENCED  FRAME 
bytes  . 

5-  36 

char*32 

SH  ID  =  'SENSOR  FLIGHT' 

37-40 

long 

SH  DL  =  33 

41-73 

char*33 

SH_DS  =  'long  N,  N(long[l]),  N(double[12])’ 

74-77 

long 

NB  OF  REFERENCED  FRAME 

78-- 

long[]  [1] 

FRAME  INDEX 

“  “  “ 

double[][12] 

SENSOR  ATTITUDE 

Table  Definitions: 


long  FRAME_INDEX  [][1] :  frame  numbers  where  the  following  data  is  applicable. 

double  SENSOR_ATTITUDE  [][12]  : 

[0]  SENSOR_LONGITUDE 

[1]  SENSOR_LATITUDE 

[2]  SENSOR_ALTmJDE 

[3]  SENSOR_HEADING 

[4]  SENSOR_SPEED 

[5]  SENSOR_VERTICAL_SPEED 

[6]  SENSOR_PITCH 

[7]  SENSOR_YAW 

[8]  SENSOR  ROLL 

[9]  SENSOR  PITCH  RATE 

[10]  SENSOR  Y AW  RATE 

[11]  SENSOR  ROOL  RATE 
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Example  of  Printing  Result:  (Simulated  Datal 


Segment  index  =  551,  segment  length  =  877  bytes. 

Sensor  flight: 

Number  of  referenced  frames:  8 

Frame 

Longitude 

(deg) 

Pitch 

(deg) 

Latitude 

(deg) 

Yaw 

(deg) 

Altitude 

(m) 

Roll 

(deg) 

Heading 

(deg) 

dPitch/dt 

(deg/s) 

Horizontal 
speed  (m/s) 

dYaw/dt 

(deg/s) 

Vertical 
speed  (m/s) 

dRoll/dt 

(deg/s) 

1 

12.12345695 

45.11678838 

1000.4 

180.0 

200.0 

12.4 

0.0 

0.1 

0.0 

1.00 

2.00 

1.00 

4 

12.12345695 

45.09678838 

1001.6 

180.2 

200.0 

12.7 

0.1 

0.3 

0.1 

1.00 

2.00 

1.00 

6 

12.12345695 

45.08345505 

1002.5 

180.4 

200.0 

13.0 

0.2 

0.4 

0.2 

1.00 

2.00 

1.00 

9 

12.12345695 

45.06345505 

1003.7 

180.7 

200.0 

13.3 

0.3 

0.6 

0.3 

1.00 

2.00 

1.00 

12 

12.12345695 

45.04345505 

1004.9 

181.1 

200.0 

13.6 

0.4 

0.8 

0.4 

1.00 

2.00 

1.00 

14 

12.12345695 

45.03012171 

1005.7 

181.5 

200.0 

13.9 

0  .5 

0.9 

0.5 

1.00 

2.00 

1.00 

19 

12.12345695 

44.99678838 

1007.8 

182.2 

200.0 

14.4 

0.6 

1.3 

0.6 

1.00 

2.00 

1.00 

32 

12.12345695 

44.91012170 

1013.1 

183.2 

200.0 

15.9 

1.1 

2.1 

1.1 

1.00 

2.00 

1.00 

r 


T 
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A.7  Secondary-Header  Segment:  SENSOR_CAMERA_POINTING 


This  segment  contains  the  camera  pointing  parameters  which  can  change  in  time 
(indexed  by  the  frame  number). 

Segment  Description: 


Description 

1-4 

long 

SH_NB  =  76  +  52  *  NB_OF_REFERENCED_FRAME 
bytes. 

5-36 

char*32 

SH  ID  =  SENSOR  CAMERA  POINTING 

long 

SH  DL  =  32 

41-72 

char*32 

SHDS  =  ’long  N,  N(long[l]),  N(double[6])’ 

73-76 

long 

NB  OF  REFERENCED  FRAME 

77-80 

LONG 

ABSOLUTEPOINTING 
(1  '.absolute  in  the  Earth  frame  of  reference, 

0:  relative,  in  the  airframe  frame  of  reference) 

81  -  - 

long[][l] 

FRAME  INDEX 

-  — 

doubled  [6] 

CAMERA  POINTING 

Table  Definitions: 


long  FRAME_INDEX  [][1]  :  frame  number  where  the  following  data  is  applicable. 


double  CAMERA  POINTING  []  [6] : 

[0]  AZIMUTHAL  AN GLE 

[1]  ELEVATIONANGLE 

[2]  ROTATIONANGLE 

[3]  AZIMUTHAL_AN GLE  RATE 

[4]  ELEVATIONANGLERATE 

[5]  ROTATION  ANGLE  RATE 


r 
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Example  of  Printing  Result:  (Simulated  Data") 

Segment  index  =  1428,  segment  length  =  4  92  bytes. 

Camera  pointing: 

Number  of  referenced  frames:  8 


Frame 

Azimuth 

angle 

(deg) 

Elevation 

angle 

(deg) 

Rotation 

angle 

(deg) 

Azimuth 

spin 

(deg/s) 

Elevation 

spin 

(deg/s) 

Rotation 

spin 

(deg/s) 

1 

90.50 

-44 . 90 

0.60 

15.00 

3.00 

12.00 

4 

92.00 

“44.60 

1.80 

15.00 

3.00 

12.00 

6 

93.00 

-44.40 

2.60 

15.00 

3.00 

12 . 00 

9 

94.50 

-44 .10 

3.80 

15.00 

3.00 

12.00 

12 

96.00 

-43.80 

5.00 

15.00 

3.00 

12.00 

14 

97.00 

-43.60 

5.80 

15.00 

3.00 

12.00 

19 

99.50 

-43.10 

7.80 

15.00 

3.00 

12.00 

32 

106.00 

-41.80 

13.00 

15.00 

3.00 

12.00 

F 


T 
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A.8  Secondary-header  segment:  GEOREFERENCES 

This  segment  contains  the  information  required  to  geo-reference  an  image.  It 
contains  a  set  of  longitude  and  latitude  for  the  TOP,  BOTTOM,  LEFT  and  RIGHT  pixels 
of  the  image  comers  or  other  pixel,  as  specified  by  the  table  REFERENCED_PIXEL. 
With  this  approach,  the  geo-references  are  not  necessarily  applied  to  the  real  image 
comers  but  rather  with  the  pointed  pixel.  For  example,  in  the  case  where  the  horizon  is 
included  in  the  image,  the  TOP  JLEFT  pixel  (which  is  usually  the  image  comer  with  the 
index  [0][0]  in  C  or  (1,1)  in  Fortran)  can  be  replaced  by  a  pixel  located  below  the 
horizon,  otherwise,  it  would  be  impossible  to  geo-reference  a  pixel  that  shows  the  sky. 
Also,  this  segment  can  contain  many  sets  of  geo-references,  each  set  being  associated 
with  a  specific  frame  of  the  image  sequence. 


Segment  Description: 


Byte 

E5S39B1 

Description 

1-  4 

long 

SH  NB  =  88  +  100  * 

NB  OF  REFERENCED  FRAME  bytes. 

5-36 

char*32 

SH  ID  = 'GEOREFERENCES' 

37-40 

long 

SH  DL  =  44 

41-84 

char*  44 

SH_DS  =  'long  N,  N(long[l]),  N(long[8]),  N(double[8])' 

85-88 

long 

NB  OF  REFERENCED  FRAME 

89-- 

long[]  [1] 

FRAME  INDEX 

-  — 

long[)  [8] 

REFERENCED  PIXEL 

— 

double  []  [8] 

GEOREFERENCES 

Table  Definitions: 

long  FRAMEJNDEX  [][1] 

long  REFERENCEDPIXEL  []  [8]: 

[0]  TOP_LEFT_SAMPLE 

[1]  TOP_LEFT_LINE 

[2]  TOPRIGHTSAMPLE 

[3]  TOPRIGHTLINE 

[4]  BOTTOM_LEFT_SAMPLE 

[5]  BOTTOM  LEFT  LINE 

[6]  BOTTOM JtIGHT_SAMPLE 

[7]  BOTTOM_RIGHTJLINE 

double  GEO_REFERENCES  □  [8]: 

[0]  TOP_LEFT_LONGITUDE 

[1]  TOPLEFTLATITUDE 

[2]  TOP_RIGHT_LONGITUDE 

[3]  TOP_RIGHT_LATITUDE 

[4]  BOTTOM  LEFT  LONGITUDE 

[5]  BOTTOM_LEFT_LATITUDE 

[6]  BOTTOM_RIGHT_LONGITUDE 

[7]  BOTTOMRIGHTLATITUDE 
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Example  of  Printing  Result:  (Simulated  Data") 


Segment  index  =  1920,  segment  length  =  888  bytes. 

Geo-references : 

Number  of  referenced  frames:  8 


Frame  Corner  -  Pixel  -  -  Geo-references  - 

Sample  Line  Longitude  Latitude 

(deg)  (deg) 


1  TL 

TR 
BL 
BR 

4  TL 

TR 
BL 
BR 

6  TL 

TR 
BL 
BR 

9  TL 

TR 
BL 
BR 

12  TL 

TR 
BL 
BR 

14  TL 

TR 
BL 
BR 

19  TL 

TR 
BL 
BR 

32  TL 

TR 
BL 
BR 


1  1 

1  512 

512  1 

512  512 

1  1 

1  512 

512  1 

512  512 

1  1 

1  512 

512  1 

512  512 

1  1 

1  512 

512  1 

512  512 

1  1 

1  512 

512  1 

512  512 

1  1 

1  512 

512  1 

512  512 

1  1 

1  512 

512  1 

512  512 

1  1 

1  512 

512  1 

512  512 


100.10000000 

98.00000000 

100.10000000 

98.00000000 

100.10000000 

98.00000000 

100.10000000 

98.00000000 

100.10000000 

98.00000000 

100.10000000 

98.00000000 

100.10000000 

98.00000000 

100.10000000 

98.00000000 

100.10000000 
98.00000000 

100 .10000000 
98.00000000 

100.10000000 

98.00000000 

100.10000000 

98.00000000 

100.10000000 

98.00000000 

100.10000000 

98.00000000 

100.10000000 

98.00000000 

100.10000000 

98.00000000 


45.00000000 

45.00000000 

44.00000000 

44.00000000 

45.00000000 

45.00000000 

44.00000000 

44.00000000 

45.00000000 

45.00000000 

44.00000000 

44.00000000 

45.00000000 

45.00000000 

44.00000000 

44.00000000 

45.00000000 

45.00000000 

44.00000000 

44.00000000 

45.00000000 

45.00000000 

44.00000000 

44.00000000 

45.00000000 

45.00000000 

44.00000000 

44.00000000 

45.00000000 

45.00000000 

44.00000000 

44.00000000 


End  of  secondary  header  reached,  total  length 


2807  bytes. 


SSS==SS=S==S=SSSSSS8S 


f 


T 
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FICHE  DE  CONTRdLE  DU  DOCUMENT  "j 

1.  PROVENANCE  (Is  nom  et  1'adresse) 
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2.  COTE  DE  SECURITE 
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J  Note  technique 
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8.  PARRAIN  (le  nom  et  1’adresse) 

5EB12 

i 

0  9a.  NUM£RO  DU  PROJET  OU  DE  LA  SUBVENTION 
n  (Specifier  si  c’est  un  projet  ou  une  subvention) 

9b.  numEro  DE  CONTRAT 

10a.  NUMERO  DU  DOCUMENT  DE  L'ORGANISME  EXPEDITEUR 
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